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A METHOD AND APPARATUS TO PROVIDE A 
HUMAN-USABLE INTERFACE TO 
CONVERSATIONAL SUPPORT 

CROSS-REFERENCE TO RELATED APPLICATION 

5 This application is related in subject matter to co-pending application 

Serial No. 10/128,864 filed April 24, 2002, by Hanson et al. for "Apparatus 
and Method for Providing Modular Conversation Policies and Agents" (IBM 
Docket YOR920020017US1) and assigned to a common assignee herewith. 
The disclosure of application Serial No. 10/128,864 is incorporated herein by 
10 reference. 

DESCRIPTION 
BACKGROUND OF THE INVENTION 

Field of the Invention 

The present invention generally relates to conversational mode data 
15 processing systems and, more particularly, to a specification to extend 

Application Program Interfaces (APIs) to enable human users to interact with 
conversation-enabled applications. 
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Background Description 

Conversation support proposes and implements a conversational model 
of interaction between autonomous, intelligent entities. This is achieved by 
exchanging a sequence of correlated messages. At the heart of the 
5 conversation support technology is the notion ?i conversation policy, that 

specifies the choreography of message exchange by constraining the sequence 
in which messages are sent and received, the format of individual messages 
and any timing restrictions. Each entity in the conversation is enabled with a 
conversation support module that executes one or more of these conversation 

10 policies. In addition the conversation support module mediates between the 

messaging infrastructure and the decisions made by the entities at various 
points in the conversation. 

Our work hitherto has focussed on providing conversation support to 
solve e-business integration problems for Business-to-Business (B2B) and 

15 Enterprise Application Integration (EAI), In B2B, conversation support 

facilities e-business interactions between BPM modules of trading partners. In 
case of EAI, conversation adapters provide a means to model complex 
interactions with an enterprise information system like SAP, Siebel, Ariba etc. 
This invention takes the next step in Human Computer Interaction (HCI), by 

20 enabling a human-useable interface to conversation support. 

One such human-usable interface is a Web browser. Web'browsers are 
ubiquitous on personal computers. Traditionally, a web browser is used as a 
"dumb" client to display content served up by a Web server. Web browsers 
may also be used to channel user requests to the server for further processing. 

25 Providing conversation support technology as a browser plugin enables the 

user to download conversation policies of his or her choice and interact with 
peer systems that support a compatible policy. For example, a user can 
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download his or her favorite travel booking policy TAQuicklOl from an 
independent policy provider and use that to create his or her travel 
reservations with Amex Travels who also support the same policy (amongst 
numerous other travel policies). 
5 The architecture of a system in which conversation support is provided 

in a browser plugin was described in the paper entitled "Conversational 
Browser" available on Conversation Support Website 
(http://www.research.ibm.com/convsupport). 

While Web browsers on personal computers are an especially good 

10 example of a human-usable interface, many communication devices now in 

use or envisioned do not support a Web browser. Empowering the user of 
communication devices, such as wireless personal digital assistants (PDAs), 
cell phones with PDA functionality, and the like, will change the entire 
Business-to-Consumer (B2C) business landscape. With the availability of 

15 more and more innovative conversation policies, the user has more choices 

and better influence on the quality of service of the provider. 



SUMMARY OF THE INVENTION 



It is therefore an object of the present invention to provide a human- 
usable interface to conversation support which supports multiple different 
20 communication devices. ' 

It is a further object of this invention to provide a human-usable 
interface to conversation support which does not require the installation of 
specialized software on the client communication device. 

According to the invention, a conversation support framework 
25 supports long running human interactions. The salient features of the 

implementation are the following: 
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• a small footprint, 

• automatic generation of views to show messages received in the 
conversation and screen forms to solicit decision input from the user, 
plug and play support for various on-wire message formats, viz., XML, 

5 WSDL, serialized Java, etc., and 

• plug and play support for various incoming and outgoing messaging 
protocols, viz., e-mail, http, web services etc. 

The invention also includes the contracts required to be fulfilled by an 
independent policy provider. We have also defined an archive format for 

10 bundling of conversation policies and message schemas. It is called a PoUcy 

Archive format or PAR. Policy archive files will have the file extension of 
"par". In addition, a presentation archive format has been defined to contain 
the presentation fomiats for PAR files. It is called a Policy Presentation 
Archive or PPAR. Conceptually, they are "skins" that adorn conversation 

15 policies for presentation on the browser. Policy Presentation Archive files will 

have the file extension of "ppar". 



BRIEF DESCRIPTION OF THE DRAWINGS 



The foregoing and other objects, aspects and advantages will be better 
understood from the following detailed description of a preferred embodiment 
20 of the invention with reference to the drawings, in which: 

Figure 1 is a block diagram illustrating the relation of the invention to 
the conversation management architecture and system; 

Figure 2 is a block diagram showing a preferred embodiment of the 
invention, wherein a browser running on a client device is connected to a web 
25 server which provides conversation support for the client; 
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Figure 3 is a block diagram showing a conversation-enabled server 
capable of connecting to a variety of different user devices; 

Figure 4 is a block diagram illustrating the presentation support 
according to the invention; 
5 Figure 5 is a block diagram illustrating by way of example a customer 

interaction with a restaurant service; 

Figure 6 is a block diagram showing a conversation-enabled server 
configured as a third-party provider of conversation-support services to 
subscribing users; 

10 Figure 7 is a data flow diagram of the process of installing the 

restaurant service; 

Figure 8 is a data flow diagram of the process of loading the restaurant 
service; 

Figure 9 is a data flow diagram of the process of choosing 
15 conversation parameters of the restaurant service; 

Figure 10 is a data flow diagram of the process of initiating the 
conversation in the restaurant service; 

Figure 11 is a data flow diagram of the process of sending a message 
which involves rendering the data input form; 
20 Figure 12 is a data flow diagram of the process of sending a message 

which involves sending the entered data; 

Figure 13 is a data flow diagram of the process of receiving a message 
which involves rendering the received message; 

Figure 14 is a data flow diagram of the process of receiving a message 
25 which involves responding to the received message; and 

Figure 15 is a program flow diagram of the interaction between a 
conversation-support services host and a subscriber. 
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DETAILED DESCRIPTION OF A PREFERRED 
EMBODIMENT OF THE INVENTION 

The word "conversation" essentially describes the act of two or more 
parties or entities interacting with each other to achieve a meaningful end. 
5 "Conversation support" elucidates an architecture, specification and 

infrastructure required to support multi-step, stateful interactions between 
components. Conversation support for electronic business (e-business) 
extends the notion of human conversation to the realm of electronic 
transactions. It is an architecture by which two or more computers belonging 
10 to different parties can "talk" with each other to conduct business over a 

network, such as the Internet. The architecture is grounded on two main 
concepts: 

The conversation verbiage. The conversation verbiage includes the act 
of initiating/terminating a conversation and the act of 
15 sending/receiving a message in conversation. 

The sequence or rules governing the conversation. This is specified 
using a Conversation Policy (CP) that provides a transcript describing 
the interaction. Conversing parties follow this common script to speak 
as and when required. 

20 Take, for example, a conversation between a buyer and a seller governed by a 

CP that deals with haggling on the price for the purchased commodity. The 
buyer may receive offers from the seller and make counter-offers to the seller. 
As a result, the buyer and seller would need to decide whether to agree or 
disagree with an offered price. If the buyer agrees to a seller's offer, a 

25 confirmation is sent to the seller, but if not, the seller may send a counter-offer 

to the seller or request the seller to send another offer. Thus, the conversation 
support mechanism side would need to pass "please decide" messages to the 
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application logic and, in turn, accept "decisions" from the application logic. 

Referring now to the drawings, and more particularly to Figure 1 , there 
is shown a block diagram providing an overview of the invention. This 
represents one of the participants in the conversation; that is, it is assumed that 
5 there are two parties connected to a messaging bus 10, such as the Internet. 

Only one of these parties 12 is shown, but it will be understood that the other 
party also supports conversational interactions, so it will not be described. The 
party 12 comprises three components; a messaging endpoint 12, which 
provides the interface to the messaging bus 10, a conversation management 

10 support component 122, ^ decision logic module I23. The conversation 

management component 122 functions as indicated by way of the example of 
the included state chart diagram. That is, the conversation is initiated by party 
A sending a "Request bid" message to party B. Party B receives the message, 
and a timer is started at party A. This timer is set for some arbitrary time, say 

15 60 seconds, and if it times out, the negotiation is canceled. However, if before 

the timer times out party B sends a bid to party A, party A can do one of three 
things in reply. First, party A may send a "Reject" message to party B, ending 
the negotiation. Second, party A may send an "Accept" message to party B, 
concluding an agreement. Third, party A may send a "Counter bid" message to 

20 party B. If a "Counter bid" message is sent to party B, party may do one of 

three things in reply, similar to party A as just described. It ill be appreciated 
that the particular messages and sequencing rules described here are 
illustrative examples only. As shown in co-pending patent application Serial 
No, 10/128,864 referenced above, the conversation support module can be 

25 configured for any set of messages and sequencing rules. In this process, the 

decision logic module I23 makes use of a human-usable interface I24 
according to the invention, enabling a person to act as the decision-making 
part of the "application logic" in the conversation. 
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Figure 2 shows in more detail the architecture of an embodiment of the 
invention in which a server, equipped with conversation support, is connected 
with a client device that has a human-usable interface. In this case, the human- 
usable interface is the browser 204, running on a user device 1 0. The user 
5 device 20 communicates with a Web server machine 200 which is attached to, 

for example, the Internet 10. The server machine 200 includes a message 
sender 201 and a message receiver 202 which together form the messaging 
endpoint 121 of Figure 1 and provide the interface to the Internet 10. The 
message sender 201 and the message receiver 202 abstract the transport 

10 mechanisms for sending and receiving messages. The message sender 201 and 

the message receiver 202 are part of the conversation server 303 which 
interfaces with the browser 204 by means of a conversation controller 205. 
The connection between the conversation controller 205 in the conversation 
server 303 and the browser 204 in the user machine 200 is now made by way 

1 5 of the Internet 30 using a protocol such as hypertext transfer protocol (http). 

The browser 204 may be a standard Web browser, such as Internet Explorer. 
The conversation controller 205 is an application component, such as a 
servlet, that implements the communication interface between the browser and 
server. The server includes a conversation support module 206 which is an 

20 implementation of the conversation support interfaces. The conversation 

support module 206 is configured with one or more conversation policies 
(CPs), which may have been obtained, for example, from a third party in the 
form of policy archive (PAR) files. Details of the operation of the 
conversation support module 206 may be had by reference to co-pending 

25 patent application Serial No. 10/128,864. The conversation support module 

206 accesses a policy archive (PAR) 207 and generates messages, under the 
control of the conversation controller 205, which are sent by the message 
sender 201 and passes received messages from the message receiver 202 to the 
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conversation controller 205. The PAR 207 is a formatted file that contains the 
policy files and the related message schemas. In parallel with the conversation 
support module 206, a presentation support module 208 accesses a policy 
presentation archive (PPAR) 209 and, through the conversation controller 206, 
5 generates the graphic user interface (GUI) supported by the browser 204. The 

presentation support module 208 is responsible for handling the presentation 
needs of the conversational browser 204. The PPAR 209 is a formatted file 
containing the presentation mappers from message schemas to the display 
screen (not shown) of the user machine 200. A repository explorer 210, 

10 controlled by the conversafion controller 206, maintains an archive repository 

database 21 1 of the "conversation" between the user machine 200 and another 
party's machine (not shown). The repository explorer 210 is a user interface 
(UI) screen flow to manage the archive repository 21 1. The purpose of the 
archive repository database 211 is to maintain the downloaded policy archives 

1 5 and presentation archives. 

The same functions can be supported in servers equipped to connect 
with user devices other than browsers, as shown in Figure 3. Without limiting 
the generality of the invention, only three types of user device are shown in the 
figure. Each of the user devices 301, 302 and 303 shown interacts with the 

20 conversation server 3 1 1 on a remote machine 3 1 0, using a communication 

channel appropriate to that device type. In this example, user device 301, 
which is the same device as the user machine 20 and browser 204 in Figure 2, 
communicates with the server using the Internet 30, as in Figure 2. User 
device 302 uses the Internet to send and receive WML (Wireless Markup 

25 Language) messages. User device 303 uses a voice and text connection to send 

and receive information. The information exchanged between the server and 
each type of user device is specific to that device type. The server 
accommodates a multiplicity of device types by means of presentation policy 
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archives (PPAR) 209, stored in the archive repository 211. For combination of 
conversation policy and device type, a different presentation poHcy archive is 
used to generate markup appropriate to that device type and conversation 
policy. 

5 The presentation support module 208 is shown in more detail in Figure 

4. The presentation support module is responsible for presenting the messages 
to the user, processing the user messages and formatting the messages through 
message formatters. More particularly, the presentation support module 
includes a presentation controller 41 which controls a message formatter 
10 factory 42 and message formatters 43. A translation engine 44 is used to 

generate the messages which are presented on the user device. The formatted 
messages are sent to the participating parties through the conversation support 
module 206. 

The message formatters 43 are responsible for translating incoming 
15 messages from message schemas to presentable markup, and translating 

outgoing message data to an outgoing message. The message fomiatter factory 
42 is responsible for instantiating a particular type of message formatter. The 
message formatter 43 uses message mappers from the presentation archive 
(PPAR) 209 to translate messages and schemas using the translation engine 
20 44. There are four types of mappers: 

Incoming Message Mapper. In the preferred embodiment, conversing 
parties in a conversation exchange XML (extensible Markup Language) 
messages. A human participant may receive conversation messages through 
message receivers (i.e., 202 in Figure 2). These messages are, typically, in 
25 XML format. The conversational browser renders these messages to the user 

through mapping to markup screens. A presentation archive (PPAR) contains 
one mapping per incoming message schema. These XML style sheet files 
translate incoming messages to markup screens. 
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It should be noted that XML is but one example of an on-wire message 
format and other formats could be used in alternative implementations of the 
invention. The architecture allows for plugging in the appropriate message 
formatter based on the on-wire message format. Thus, while the preferred 
5 embodiment of the invention uses XML, other on-wire formats, and 

corresponding formatters, may be used in the practice of the invention. 

Schema Markup Mapper: As part of a conversation, a user sends 
messages to other conversing parties. When a user is required to send a 
message, the browser renders a form to collect message data. This markup 

10 mapper is a screen that renders this form. These screens are defined per 

outgoing message schema in the presentation archive (PPAR) file. They 
implicitly assume the structure of the outgoing message. 

Schema Translation Mapper: Like the schema markup mapper, these 
mapping files map outgoing message schemas to markups that render a form 

1 5 to collect the outgoing message data. These XSL (extensible Style Language) 

style sheet mappings are more dynamic and can absorb easily any changes in 
the schema. Unlike schema markup mappers, these mapping files do not "hard 
code" screens; rather, the screens are generated by translating the message 
schema with this schema translator XSL style sheet. A policy presentation 

20 archive may provide one of the schema markup mapper or schema translation 

mapper per outgoing message schema. 

Outgoing Message Mapper: Outgoing message data is collected from 
the user as name-value pairs. These mapping XSL style sheets translate these 
name-value pairs to outgoing XML messages. 

25 The following are the major functionalities of the presentation support 

module: 

Format the incoming messages and provide presentable markup to the 
user device: An incoming message received through the message 
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receiver 202 may not be in a form desirable for presentation to the 
user. The presentation support module translates these messages to 
markup appropriate for the user device using the "incoming message 
mappers'* from the presentation archive (PAR) 207. The translated 

5 markup is sent to the user device for rendering 204. 

The conversation controller 205 queries the conversation support 
module 206 for any possible actions in the current conversation state. 
For example, it is frequently the case that, after a certain message has 
been received, the conversation policy in use specifies a set of specific 

0 responses - i.e., potential actions - that are available to the user. These 

actions are passed to the presentation support module 208, mapped to 
markup and presented to the user. Each action may require a message 
to be sent, this information is retrieved from the conversation support, 
and mapped to the markup through the schema markup mappers and/or 

5 schema translation mappers from the presentation archive (PPAR) 

209.. The transformed markup is sent to the conversation controller 
205 for transmission to the user device. 

Format the user submitted data to the message schemas: The user 
submits the message data through forms. This data needs to be 
0 formatted before handing over to the conversation support. Message 

data is collected as name-value pairs from the user. The presentation 
support module 208 uses the outgoing message mappers from 
presentation archives (PPAR) 209 to format messages to conform to 
the message schemas. 

5 Figure 5 provides an illustration of one example in the way in which 

the invention may be used. This example is a restaurant service application 
hosted by a telephone company (also known as the service provider). In this 
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example, the service provider provides the customer with a list of restaurants 
that have signed up with the service provider. The customer (user) is looking 
for a restaurant near his or her present location. The restaurant service 
application guides the customer to select one of the restaurants. When the 
5 customer makes a selection, the restaurant service application passes control 

to the selected restaurant's order service to enable the customer to make a 
reservation or place an order for take out. 

The presentation to the customer (user) is shown at 50. This 
presentation is divided into three areas (or windows) 501, 502 and 503. Area 

10 501 shows the role of the user. Area 502 shows the last message received from 

the service provider. Area 503 prompts the user to make a selection and send 
the selection as his or her message. Block 51 shows an example of the literal 
"conversation" between the customer and the service provider (SP). In this 
conversation, the customer is provided with three choices, but upon making a 

1 5 choice is told that the selection is ten miles away. The customer considers this 

too far and asks for something closer. There is only one choice within the 
milage constraint, and that choice is selected. At this point in the conversation, 
the service provider transfers the user to the selected restaurant' order service 
to make reservations or order carry out. 

20 The literal conversation in block 5 1 is mapped to the conversation 

policy (CP) generally indicated by the state diagram in block 52, and the 
conversation is presented to the customer as illustrated in block 50. More 
specifically, the process begins at 521 by the user (customer) contacting the 
service provider requesting restaurants near his or her location. In response to 

25 this query, the service provider generates a listing 522 which is communicated 

to the user's machine and displayed in area 502. After the service provider 
provides a listing of restaurants near the user's current location, the user has to 
select one from the list. The selection is passed to the service provider, and the 
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service provider responds by providing more details about the selected 
restaurant, such as cuisine type, hours, price ranges, etc. The service provider 
then waits at 523 for a response from the user. Now, the user may do one of 
three things at 524; the user may (1) accept a selection, (2) request a re- 
5 selection or (3) reject the selections offered. This continues in a loop, until the 

user chooses to accept a particular choice. If, as in the scenario of the 
conversation illustrated in block 51, the user requests a re-selection, a new 
listing is provided by the service provider at 525, which allows the user the 
same three options as before. If, again as in the scenario of the conversation 

1 0 illustrated in block 5 1 , the user finally accepts a selection, a transfer is made to 

the selected restaurant at 526. The user could, of course, reject the selections 
provided, in which case the process ends at 527. In each of the states, the 
presentation 50 is automatically rendered, based on the conversation policy 
(CP) in use, the current state, and the current state's transitions, as shown by 

1 5 the example of block 52. 

Figure 6 shows a conversation server 601 which is a third-party 
provider of conversation-support services for users which subscribe to it. The 
users interact with the conversation server 601 through a variety of client user 
devices 610, 61 1 and 612. The conversation server 601 obtains conversation 

20 policies and presentation policies in the form of PAR files 604 and PPAR files 

603 from a third-party policy supplier 602. The policy supplier also provides 
PAR files to the service providers 620, 62 1 , and 622 with which 'the 
conversation server 601 carries on conversations. 

The following data flow diagrams illustrate how the policies are 

25 installed on the conversation support server, how a customer initiates the 

restaurant service conversation with the service provider, how the customer 
fills up and sends a message in conversation, and how a message received 
from the service provider is handled. Referring first to Figure 7, the process by 
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which the customer installs a new conversation policy and presentation policy 
(the restaurant service) is shown. In steps 1 to 5, the customer uses the user 
device to log onto the server, which, in turn, sends back to the user device a 
list of options that the user might take. At logon time, the server detects the 
5 user device type. The user device type will be used later to select the 

presentation policy archive (PPAR) appropriate to that device type. In steps 6 
to 14, the customer selects the option of downloading a policy archive 207, 
supplying the URL (uniform resource locator) of a service provider from 
which to obtain it. The downloaded policy archive 207 (restaurant.par) is then 
10 stored on the server in the archive repository. In steps 15 to 23, the customer 

asks the server to download the corresponding presentation archive 209. The 
downloaded presentation archive (restaurant.ppar) is stored in the archive 
repository. 

In Figure 8, the restaurant service is loaded. In steps 1 to 5, the 
15 customer opens the user device and logs onto the server. In steps 6 to 13, the 

customer asks the server to list the policy archives available locally. The 
customer selects the restaurant service. In steps 14 to 22, the customer asks the 
server to list the presentation archives available for the restaurant service. The 
list is retrieved from the repository archive and displayed on the browser. The 
20 customer chooses to use the presentation policy from ABC.com. 

In Figure 9, the conversation parameters are chosen. In step 24, the 
server prompts the customer to choose the role he or she wants to play in the 
— conversation. In this case, two choices are displayed: "customer" and "service 

provider". In steps 25 and 26, the customer chooses the "customer" role. In 
25 step 40, a summary of the choices are displayed which, in this example, are: 

Policy Archive: restaurant.par 
Presentation Archive: restaurant.ppar 
Role Played: Customer 
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In Figures 8 and 9, the conversation policy is selected first, and the 
partner (i.e., the other party with whom the conversation is to be held) is 
chosen second, based on a prior choice of the conversation policy. This is only 
one possible order whereby the conversational parameters may be specified. 
5 Alternatively, the user might first select a conversational partner, for example, 

by specifying the URL of the messaging endpoint provided by that partner, 
and then specify a CP to use, subject to the constraint that the chosen CP must 
be supported by the partner. 

Figure 10 shows the process of initiating a conversation. In steps 42 

10 and 43, the customer instructs the server via the user device to start the 

conversation. In step 44, conversation support module 206 light weight 
implementation is instantiated. In step 45, the conversation controller 205 
registers itself with the conversation support module 206 to get receive 
messages. In step 46, the process "initiate conversation" is invoked on the 

15 conversation support module 206, passing in the conversation policy (CP) to 

load, the role played and the respective transport descriptors. In steps 48 to 50, 
the conversation identifier returned is stored by the conversation controller 
205 and indicates back to the user device the successful conversation 
initiation. The conversation enters the "Start" state. In step 51, the presentation 

20 archive 209, restaurant.ppar, is loaded by the presentation controller. In step 

52, the conversation support module 206 is queried to find out who gets to 
"speak" in the current conversation state and what it is that he or she can say. 
From the conversation policy, after the conversation is set up, the customer is 
required to send to the service provider the location information to get 

25 restaurant listings. This choice is returned in step 53 as a resuU of the query. In 

step 54, the choice is shown to the customer. 

Figure 1 1 shows the process of rendering a data input form as part of 
the process of sending a message. In step 1, the customer selects the choice to 
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enter location information. In steps 2 to 1 1, the selection in step 1 triggers the 
server to obtain the message markup to render the appropriate form on the. user 
device for the customer to enter data. This involves creating the appropriate 
message formatter 43 (in this case, the XSL formatter) and using the mappers 
5 from the presentation archive 209 corresponding to the "Location Info'* 

message schema and the type of user device. For example, suppose that the 
user device is a PDA. The translation engine then produces the Wireless 
Markup Language (WML) snippet that is sent to the PDA for rendering. 

Figure 12 shows the process of sending the entered data as part of the 

1 0 process of sending a message. In step 12, the customer enters the location data 

("Hawthorne, NY" in the example). In steps 13 to 22, the data is submitted to 
the server and, using the outgoing message mappers, is converted to a format 
appropriate for sending to the partner. In step 23, the conversation controller 
205 sets the role (customer) and conversation ID in the conversation record so 

15 that it can be processed and redirected to the appropriate conversation sessions 

on the service provider. In step 24, the "send Message In Conversation" 
method is invoked on the conversation support module 206. After the message 
has been sent, the conversation enters the "Query Made" state, as defined by 
the conversation policy. In steps 25 to 27, the conversation controller 205 then 

20 queries the conversation support module 206 for the next set of "Choices" 

available for the "customer" role. In this case, there are no choices since the 
conversation policy indicates that, at this point, the customer needs to await a 
respons^rom the service provider. 

Figure 13 shows the process of rendering a received message as part of 

25 the process of receiving a message. The service provider responds with the list 

of restaurants available near Hawthorne, NY. In step 1, the message is 
received via the Message Receiver and propagated to the conversation support 
module 206. In steps 2 and 3, the conversation support module 206 notifies 
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the conversation controller 205 of the incoming message and passes the 
message to it. The conversation state changes to "Awaiting Selection", as 
defined by the installed conversation policy. In steps 4 to 13, as before, the 
restaurant listing XML message is mapped using the incoming message 
5 mappers from the presentation archive 209 into, for example, WML. This 

WML is then transmitted to the PDA w^hich renders it. 

Figure 14 shows the process of responding to a received message as 
part of the process of receiving a message. In step 14, the conversation 
controller 205 queries the conversation support module 206 and finds out the 

10 current options available for the "customer". In step 15, from the installed 

conversation policy, the customer needs to select a restaurant in the "Awaiting 
Selection" conversation state. In steps 16 to 23, the message mappers from the 
presentation archive 209 are used to create the appropriate WML form, which 
is sent to the PDA for rendering. The customer selects the restaurant and 

1 5 transmits the selection back to the server. The server selects the appropriate 

outgoing message mapper to convert the data receive from the PDA into a 
message of the correct format as defined by the conversation policy, and sends 
the formatted message to the other party. The conversation continues until the 
conversation enters a terminal state (rejection or selection). 

20 Figure 15 is a program flow diagram showing the interaction between 

the conversation support services host 601 and one of the subscribers 610, 61 1 
and 612, shown in Figure 6. In step 1501, the subscriber (also referred to as 
"client") logs onto the host 601. In step 1502, the host then identifies the type 
of user device in use and stores this information for later use in selecting the 

25 presentation policies appropriate to that device. In step 1503, the server 

accesses client subscription information, such as a list of service types the 
subscriber is interested in, and based on that information and on the type of 
user device, the server sends a list of available third-party services with which 
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the user may initiate a conversation. After the client selects a service in step 
1504, the host 601 initiates a conversation with that service in step 1505. 
Thereafter, in step 1506, the conversation proceeds between the host and the 
selected service, with the host sending information to, and gathering 
information fi*om, the user device as necessary. In step 1507, the conversation 
terminates. In step 1508, the host prompts the user as to whether the user 
wishes to disconnect or to carry on another conversation with the selected 
service. If the user chooses to continue, step 1506 is executed again. 
Alternatively, the process could retum to step 1503 so that the list of services 
is presented again for selection. If the user chooses not to continue, the client 
is logged off in step 1 509. 

While the invention has been described in terms of a single preferred 
embodiment, those skilled in the art will recognize that the invention can be 
practiced with modification within the spirit and scope of the appended 
claims. For example, it will be understood that the specific example of a 
restaurant service is but one of many applications which may be implemented 
with the present invention. Other services might include lodging, for example. 
And other service providers besides the telephone company may be used. The 
human-usable interface according to the invention may run on any human 
interaction device and not just personal computers (PCs) and personal digital 
assistants (PDAs). For example, cell phones and other such devices supporting 
the human-usable interface may be used. It is also possible for the client (user) 
to conduct multiple conversations simultaneously, say while buying 
merchandise from an online store and making sure that there are available 
funds with the bank. 



